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CLAIMS 

1. (currently amended) A method of limiting unauthorized network requests, 
comprising the steps of: 

identifying entities legitimately entitled to service, wherein an entity 
comprises a user id-client pair, said user id-client pair comprising an individual 
user-machine combination; 

establishing said identified entities as trusted entities by issuing a trust 
token for each entity successfully authenticating to said network service, said 
trust token comprising a data object that includes a client identifier, said client 
identifier comprising at least one item of data that can be used to uniquely 
identify the client machine, wherein [[a]] said user ID-client pair represents a 
unique entity; 

storing said issued trust token on said client: 

transmitting said stored issued trust token along with said user ID, 
authentication credentials, and client identifier from said client to said network 
service : 

processing requests from said trusted entities according to a first policy; 

and 

processing remaining requests according to at least a second policy. 

2. cancelled 

3. (cancelled) 

4. (previously presented) The method of claim 1 , wherein entities legitimately 
entitled to service comprise entities previously able to successfully authenticate 
to a network service. 

5. (original) The method of claim 4, wherein said network service comprises 
a server. 
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6. cancelled 

7. cancelled 

8. (previously presented) The method of claim 1, said data object including: 
said user ID or a derivative thereof. 

9. (original) The method of claim 8, wherein said derivative comprises a 
cryptographic hash of the user ID. 

10. (original) The method of claim 8, wherein said data object further includes 
any of: a time stamp of first authentication to said network service by said entity; 
and a time stamp of a most recent authentication to said network service by said 
entity. 

1 1 . cancelled 

12. (previously presented) The method of claim 1, said client identifier 
comprising any of: a client identifier assigned by said network service; and a 
client identifier provided by the client. 

1 3. (previously presented) The method of claim 1 , further comprising a step of 
encrypting said trust token. 

14. (original) The method of claim 13, further comprising the step of: 
transmitting said trust token from said network service to said client upon 
successful authentication to said network service by said entity. 

15. (original) The method of claim 14, wherein said step of transmitting said 
trust token occurs via a secure channel. 
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16. (original) The method of claim 15, wherein said secure channel comprises 
a network connection secured via the SSL (secure sockets layer) protocol. 

17. cancelled 

18. cancelled 

19. (currently amended) The method of claim 1[[8]], wherein said step of 
transmitting said stored, issued trust token occurs via a secured channel. 

20. (original) The method of claim 19, wherein said secured channel 
comprises a network connection secured via the SSL (secure sockets layer) 
protocol. 

21 . (original) The method of claim 12, further comprising a step of storing said 
issued trust token in a server side database, indexed according to a combination 
of user ID and client identifier. 

22. (original) The method of claim 21, further comprising the step of: 
transmitting said client identifier assigned by said network service from said 
network service to said client upon successful authentication to said network 
service by said entity. 

23. (original) The method of claim 22, wherein said step of transmitting said 
client identifier assigned by said network service occurs via a secure channel. 

24. (original) The method of claim 22, said secure channel comprising a 
network connection secured via the SSL (secure sockets layer) protocol. 
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25. (original) The method of claim 21, further comprising the steps of: 
transmitting said user ID and client identifier to said server; and retrieving said 
stored trust token from said database. 

26. (original) The method of claim 21, wherein said server side database 
serves a plurality of services. 

27. (previously presented) The method of claim 1 , wherein processing 
requests from said trusted entities according to a first policy comprises the steps 
of: 

validating said trust token; and 

processing request without adding incremental response latency. 

28. (original) The method of claim 27, wherein said step of validating said trust 
token comprises the step of: 

verifying that the user ID and a client identifier in the trust token match 
those presented by the client on the request. 

29. (previously presented) The method of claim 28, wherein said step of 
validating said trust token further comprises any of the steps of: 

verifying that a time stamp of a first authentication by the entity recorded in 
the trust token is no earlier than a specified earliest acceptable first- 
authentication time stamp; and 

verifying that a time stamp of a last authentication by the entity recorded in 
the trust token is no earlier than a specified earliest acceptable last- 
authentication time stamp. 

30. (previously presented) The method of claim 1, wherein processing 
remaining requests according to at least a second policy comprises adding a 
specified amount of incremental response latency when processing untrusted 
logins. 
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31. (original) The method of claim 30, wherein untrusted logins include 
successful and unsuccessful logins from entities not bearing a trust token. 

32. (previously presented) The method of claim 31, wherein response latency 
is added to a specified percentage of successful untrusted logins. 

33. (previously presented) The method of claim 2, wherein processing 
remaining requests according to at least a second policy comprises adding a 
specified amount of incremental response latency when processing requests 
from untrusted IP addresses that have exceeded a configurable login rate. 

34. (original) The method of claim 2, wherein processing remaining requests 
according to at least a second policy comprises requiring an untrusted entity to 
complete a Turing test. 

35. (original) The method of claim 1, wherein said policies are applied by a 
server. 

36. (original) The method of claim 35, wherein said server applies rate policies 
for a plurality of network devices. 

37. (original) The method of claim 6, further comprising the step of: 
updating said trust token after a login by a trusted entity. 

38. (currently amended) A computer program product comprising computer 
readable code means embodied on a tangible medium, said computer readable 
code means comprising code for performing a method of limiting unauthorized 
network requests, said method comprising the steps of: 
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identifying entities legitimately entitled to service, wherein an entity 
comprises a user id-client pair, said user id-client pair comprising an individual 
user-machine combination; 

establishing said identified entities as trusted entities by issuing a trust 
token for each entity successfully authenticating to said network service, said 
trust token comprising a data object that includes a client identifier, said client 
identifier comprising at least one item of data that can be used to uniquely 
identify the client machine, wherein [[a]] said user ID-client pair represents a 
unique entity; 

storing said issued trust token on said client: 

transmitting said stored issued trust token along with said user ID. 
authentication credentials from said client to said network service: 

processing requests from said trusted entities according to a first policy; 

and 

processing remaining requests according to at least a second policy. 

39. (cancelled) 

40. (cancelled) 

41. (previously presented) The method of claim 38, wherein entities 
legitimately entitled to service comprise entities able to successfully authenticate 
to a network service. 

42. (original) The method of claim 41, wherein said network service comprises 
a server. 

43. cancelled. 

44. cancelled. 



Page 7 of 20 



Application ser. no 10/759,596 



45. (previously presented) The method of claim 38, said data object including: 
said user ID or a derivative thereof. 

46. (original) The method of claim 45, wherein said derivative comprises a 
cryptographic hash of the user ID. 

47. (original) The method of claim 45, wherein said data object further 
includes any of: a time stamp of first authentication to said network service by 
said entity; and a time stamp of a most recent authentication to said network 
service by said entity. 

48. cancelled 

49. (previously presented) The method of claim 38, said client identifier 
comprising any of: a client identifier assigned by said network service; and a 
client identifier provided by the client. 

50. (original) The method of claim 45, further comprising the step of: 
encrypting said trust token. 

51. (original) The method of claim 50, further comprising a step of: 
transmitting said trust token from said network service to said client upon 
successful authentication to said network service by said entity. 

52. (original) The method of claim 51, wherein said the step of: transmitting 
said trust token occurs via a secure channel. 

53. (previously presented) The method of claim 52, wherein said secure 
channel comprises a network connection secured via the SSL (secure sockets 
layer) protocol. 
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54. cancelled 

55. cancelled 

56. (currently amended) The method of claim [[55]] 38, wherein said step of 
transmitting said stored, issued trust token occurs via a secured channel. 

57. (original) The method of claim 56, wherein said secured channel 
comprises a network connection secured via the SSL (secure sockets layer) 
protocol. 

58. (original) The method of claim 50, further comprising the step of: storing 
said issued trust token in a server side database, indexed according to a 
combination of user ID and client identifier. 

59. (original) The method of claim 58, further comprising the step of: 
transmitting said client identifier assigned by said network service from said 
network service to said client upon successful authentication to said network 
service by said entity. 

60. (original) The method of claim 59, wherein said step of transmitting said 
client identifier assigned by said network service occurs via a secure channel. 

61. (original) The method of claim 59, said secure channel comprising a 
network connection secured via the SSL (secure sockets layer) protocol. 

62. (original) The method of claim 58, further comprising the steps of: 
transmitting said user ID and client identifier to said server; and retrieving said 
stored trust token from said database. 
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63. (original) The method of claim 58, wherein said server side database 
serves a plurality of services. 

64. (original) The method of claim 40, wherein processing requests from said 
trusted entities according to a first policy comprises the steps of: validating said 
trust token; and processing without adding incremental response latency. 

65. (original) The method of claim 64, wherein said step of validating said trust 
token comprises the step of: verifying that the user ID and a client identifier in the 
trust token match those presented by the client on the request. 

66. (previously presented) The method of claim 65, wherein said step of 
validating said trust token further comprises any of the steps of: verifying that a 
time stamp of a first authentication by the entity recorded in the trust token is no 
earlier than a specified earliest acceptable first-authentication time stamp; and 
verifying that a time stamp of a last authentication by the entity recorded in the 
trust token is no earlier than a configurable earliest acceptable last-authentication 
time stamp. 

67. (previously presented) The method of claim 40, wherein processing 
remaining requests according to at least a second policy comprises adding a 
specified amount of incremental response latency when processing untrusted 
logins. 

68. (original) The method of claim 67, wherein untrusted logins include 
successful and unsuccessful logins. 

69. (previously presented) The method of claim 68, wherein response latency 
is added to a specified percentage of successful logins. 
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70. (previously presented) The method of claim 40, wherein processing 
remaining requests according to at least a second policy comprises adding a 
specified amount of incremental response latency when processing requests 
from IP addresses that have exceeded a configurable login rate. 

71. (original) The method of claim 40, wherein processing remaining requests 
according to at least a second policy comprises requiring an untrusted entity to 
complete a Turing test. 

72. (original) The method of claim 39, wherein said policies are applied by a 
server. 

73. (original) The method of claim 72, wherein said server applies rate policies 
for a plurality of network devices. 

74. (previously presented) The method of claim 38, further comprising the 
step of: updating said trust token after a login by a trusted entity. 

75. (previously presented) A method of establishing an entity requesting a 
network service as trusted, comprising the steps of: 

for each successful authentication, adding or updating a database record 
containing at least a user identifier, an originating network address and a 
date/timestamp of first and/or the current successful authentication; 

comparing all subsequent authentication requests to said record; 

where the user identifier of a subsequent request matches that of a 
successful authentication, extending trust to the subsequent request if its 
originating network address and timestamp information satisfy predetermined 
criteria in relation to said record; 

processing requests from trusted entities according to a first policy; and 

processing remaining requests according to at least a second policy, 
wherein processing remaining requests according to at least a second policy 
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comprises adding a configurable amount of incremental response latency when 
processing untrusted logins. 

76. (original) The method of claim 75, wherein said step of adding or updating 
a database record comprises either of the steps of: 

creating a new record by said network service if an entity has not 
previously authenticated to said network service; and 

updating a previously created record for subsequent authentication 
requests from said entity. 

77. (currently amended) The method of claim 75, wherein [[a]] said network 
address comprises ah IP (internet protocol) address. 

78. (previously presented) The method of claim 75, wherein the step of 
extending trust to the subsequent request comprises: 

extending trust if the user identification and originating network address 
match those of the record exactly, and wherein the data/timestamps from the 
record satisfy specified bounds checks. 

79. (previously presented) The method of claim 75, wherein the step of 
extending trust to the subsequent request comprises: 

when the user identifier of the subsequent request matches that of a 
record, determining a trusted address range, defined by client addresses from 
which successful authentications have originated, for the user identifier from 
stored authentication records. 

80. (previously presented) The method of claim 79, wherein the step of 
extending trust to the subsequent request further comprises: 

determining if the originating address of the subsequent request falls 
within the trusted address range, and 
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determining if the data/timestamps for the trusted address range satisfy 
specified bounds checks. 

81. (previously presented) The method of claim 79, wherein the step of 
determining if the data/timestamps for the trusted address range satisfy specified 
bounds checks comprises the steps of: 

establishing earliest date/timestamp for the trusted address range as a 
minimum for the earliest authentication timestamp; and 

establishing earliest date/timestamp for the trusted address range as a 
maximum for the earliest authentication timestamp. 

82. (previously presented) The method of claim 79, wherein the step of 
extending trust to the subsequent request further comprises: 

if the timestamps pass specified bounds checks, extending trust to the 
request. 

83. (original) The method of claim 75, wherein the entity comprises a user 
requesting the network service from an anonymous client. 

84. (original) The method of claim 83, wherein the network service comprises 
a server. 

85. (original) The method of claim 84, wherein the client and the server are in 
communication via a secured network channel. 

86. (original) The method of claim 85, said secure channel comprising a 
network connection secured via the SSL (secure sockets layer) protocol 

87. (cancelled) 

88. (cancelled) 
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89. (previously presented) The method of claim 75, wherein untrusted logins 
include successful and unsuccessful logins from untrusted entities. 

90. (previously presented) The method of claim 89, wherein response latency 
is added to a specified percentage of successful untrusted logins. 

91. (previously presented) The method of claim 75, further comprising the 
step of: 

adding a configurable amount of incremental response latency when 
processing requests from IP addresses that have exceeded a configurable login 
rate. 

92. (previously presented) The method of claim 75, further comprising the 
step of: 

requiring an untrusted entity to complete a Turing test. 

93. (previously presented) The method of claim 75, wherein said policies are 
applied by a server. 

94. (original) The method of claim 91 , wherein said server applies rate policies 
for a plurality of network devices. 
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